Sizing SAN Storage Migrations

ABSTRACT

A computer-implemented method sizes a Storage Area Network (SAN) storage migration. One or more processors determine Input/output Operations Per Second (IOPS) and throughput of hardware devices operatively coupled to a target Storage Area Network (SAN) prior to a SAN migration from a source SAN to the target SAN. One or more processors determine an estimated time and size of the SAN migration based on the IOPS and the throughput of the hardware devices. One or more processors then configure transmission resources available to the source SAN to comport with the estimated time and size of the SAN migration.

BACKGROUND

The present disclosure relates to the field of computers, andspecifically to the field of computers that are used in storage areanetworks (SANs). Still more specifically, the present disclosure relatesto the field of migrating data from a first SAN to a second SAN.

Storage migrations rely on SAN to SAN transfer of block-based datautilizing available throughput rates. Storage migrations are currentlysized according to the capacity of the telecommunications wire betweenthe originating datacenter and the receiving datacenter. The capacity ofthe wire (e.g., a physical pathway for data such as a network, anEthernet wire, etc.) provides the system with an estimate of the amountof traffic the line can handle. This line size is compared against thenumber of terabytes (TB) of data to be migrated and the number of timesthe data will be migrated. However, this type of sizing methodology doesnot take into account that one or more disks at the target SAN may bedegraded due to older technology (e.g., able to handle a lower number ofInput-output Operations Per Second (IOPS)); the response timerequirements by other workloads concurrently utilizing disk systems inthe target SAN (i.e., what response times are required to be met by jobsthat use the target SAN, which may be affected by a SAN migration); andany additional streams utilizing the SAN (such as backup migrations).

Currently, the SAN migration methodology does not utilize SANconstraints when sizing the timing of the migration. That is, only theline speed and the number of migrations are taken into account. Neitherof these factors take into account the capabilities of the target SAN orthe other workloads migrating across the fabric. That is, throughput canbe constrained by a variety of factors, including the number of IOPSthat can occur, response time, and throughput as measured by sustainedMega Byte (MB) transfer rate. Thus, constructing proper environments,restraints, and resources used during SAN migrations is oftenproblematic, since there is not a clear picture of the capabilities ofthe fabric (i.e., the source SAN, the target SAN, and the networkbetween the two SANs). This leads to improper sizing of blocks of databeing migrated from one SAN to another SAN, leading to excessivemigration times, overloading of resources in the source SAN and/or thetarget SAN, and increased error rates during the migration.

SUMMARY

In one or more embodiments of the present invention, acomputer-implemented method sizes a Storage Area Network (SAN) storagemigration. One or more processors determine Input/output Operations PerSecond (IOPS) and throughput of hardware devices operatively coupled toa target Storage Area Network (SAN) prior to a SAN migration from asource SAN to the target SAN. One or more processors determine anestimated time and size of the SAN migration based on the IOPS and thethroughput of the hardware devices. One or more processors thenconfigure transmission resources available to the source SAN to comportwith the estimated time and size of the SAN migration. This provides anew and useful improvement over the prior art, which estimated SANstorage migration time based solely on SAN-to-SAN connection bandwidth,leading to a misrepresentation of the amount of time needed for the SANmigration. The present invention overcomes this deficiency in the priorart, leading to a more robust and useful configuration of resources usedin the SAN migration.

In one or more embodiments of the present invention, one or moreprocessors further determine the estimated time and size of the SANmigration by using a SAN subsystem of the target SAN as a queuingentity, where the SAN subsystem simulates the IOPS of the hardwaredevices operatively coupled to the target SAN. This provides a morerobust system, over that of the prior art, in which IOPS of the hardwaredevices are simulated by the SAN subsystem, thus providing a moreaccurate size of the SAN storage migration.

In one or more embodiments of the present invention, a computer programproduct sizes a Storage Area Network (SAN) storage migration. Thecomputer program product includes a non-transitory computer readablestorage medium having program code embodied therewith. The program codeis readable and executable by a processor to perform a method thatincludes: determining Input/output Operations Per Second (IOPS) andthroughput of hardware devices operatively coupled to a source StorageArea Network (SAN) prior to a SAN migration from the source SAN to atarget SAN; determining an estimated time and size of the SAN migrationbased on the IOPS and the throughput of the hardware devices; andconfiguring transmission resources available to the source SAN tocomport with the estimated time and size of the SAN migration. Thisprovides an improvement over the prior art in which onlywiring/connections between the two SANs were evaluated in sizing the SANmigration, which led to improperly sizing the SAN migration. The presentinvention overcomes this problem in the prior art.

In one or more embodiments of the present invention, a system includes aprocessor, a computer readable memory, and a non-transitory computerreadable storage medium. First program instructions, when executed bythe processor, determine Input/output Operations Per Second (IOPS) andthroughput of hardware devices operatively coupled to a target StorageArea Network (SAN) prior to a SAN migration from a source SAN to thetarget SAN. Second program instructions, when executed by the processor,determine an estimated time and size of the SAN migration based on theIOPS and the throughput of the hardware devices. Third programinstructions, when executed, configure transmission resources availableto the source SAN to comport with the estimated time and size of the SANmigration. This provides an improvement over the prior art in which onlywiring/connections between the two SANs were evaluated in sizing the SANmigration, which led to improperly sizing the SAN migration. The presentinvention overcomes this problem in the prior art.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an exemplary system and network in which the presentdisclosure may be implemented;

FIG. 2 illustrates an overview of a Storage Area Network (SAN) migrationin accordance with one or more embodiments of the present invention;

FIG. 3 depicts factors utilized in a SAN migration in accordance withone or more embodiments of the present invention;

FIG. 4 illustrates an exemplary use-case of a SAN migration inaccordance with one or more embodiments of the present invention;

FIG. 5 is a high-level flow chart of one or more steps performed by aprocessor to size SAN storage migrations;

FIG. 6 depicts a cloud computing node according to an embodiment of thepresent disclosure;

FIG. 7 depicts a cloud computing environment according to an embodimentof the present disclosure; and

FIG. 8 depicts abstraction model layers according to an embodiment ofthe present disclosure.

DETAILED DESCRIPTION

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

With reference now to the figures, and in particular to FIG. 1, there isdepicted a block diagram of an exemplary system and network that may beutilized by and/or in the implementation of the present invention. Someor all of the exemplary architecture, including both depicted hardwareand software, shown for and within computer 102 may be utilized bysoftware deploying server 150 and/or source Storage Area Network (SAN)152 and/or target SAN 154.

Exemplary computer 102 includes a processor 104 that is coupled to asystem bus 106. Processor 104 may utilize one or more processors, eachof which has one or more processor cores. A video adapter 108, whichdrives/supports a display 110, is also coupled to system bus 106. Systembus 106 is coupled via a bus bridge 112 to an input/output (I/O) bus114. An I/O interface 116 is coupled to I/O bus 114. I/O interface 116affords communication with various I/O devices, including a keyboard118, a mouse 120, a media tray 122 (which may include storage devicessuch as CD-ROM drives, multi-media interfaces, etc.), and external USBport(s) 126. While the format of the ports connected to I/O interface116 may be any known to those skilled in the art of computerarchitecture, in one embodiment some or all of these ports are universalserial bus (USB) ports.

As depicted, computer 102 is able to communicate with a softwaredeploying server 150, and/or source SAN 152 and/or target SAN 154 usinga network interface 130. Network interface 130 is a hardware networkinterface, such as a network interface card (NIC), etc. Network 128 maybe an external network such as the Internet, or an internal network suchas an Ethernet or a virtual private network (VPN). In one or moreembodiments, network 128 is a wireless network, such as a Wi-Fi network.

A hard drive interface 132 is also coupled to system bus 106. Hard driveinterface 132 interfaces with a hard drive 134. In one embodiment, harddrive 134 populates a system memory 136, which is also coupled to systembus 106. System memory is defined as a lowest level of volatile memoryin computer 102. This volatile memory includes additional higher levelsof volatile memory (not shown), including, but not limited to, cachememory, registers and buffers. Data that populates system memory 136includes computer 102's operating system (OS) 138 and applicationprograms 144.

OS 138 includes a shell 140, for providing transparent user access toresources such as application programs 144. Generally, shell 140 is aprogram that provides an interpreter and an interface between the userand the operating system. More specifically, shell 140 executes commandsthat are entered into a command line user interface or from a file.Thus, shell 140, also called a command processor, is generally thehighest level of the operating system software hierarchy and serves as acommand interpreter. The shell provides a system prompt, interpretscommands entered by keyboard, mouse, or other user input media, andsends the interpreted command(s) to the appropriate lower levels of theoperating system (e.g., a kernel 142) for processing. While shell 140 isa text-based, line-oriented user interface, the present invention willequally well support other user interface modes, such as graphical,voice, gestural, etc.

As depicted, OS 138 also includes kernel 142, which includes lowerlevels of functionality for OS 138, including providing essentialservices required by other parts of OS 138 and application programs 144,including memory management, process and task management, diskmanagement, and mouse and keyboard management.

Application programs 144 include a renderer, shown in exemplary manneras a browser 146. Browser 146 includes program modules and instructionsenabling a world wide web (WWW) client (i.e., computer 102) to send andreceive network messages to the Internet using hypertext transferprotocol (HTTP) messaging, thus enabling communication with softwaredeploying server 150 and other computer systems.

Application programs 144 in computer 102's system memory (as well assoftware deploying server 150's system memory) also include Storage AreaNetwork Sizing for Migration Logic (SANSML) 148. SANSML 148 includescode for implementing the processes described below, including thosedescribed in FIGS. 2-5. In one embodiment, computer 102 is able todownload SANSML 148 from software deploying server 150, including in anon-demand basis, wherein the code in SANSML 148 is not downloaded untilneeded for execution. In one embodiment of the present invention,software deploying server 150 performs all of the functions associatedwith the present invention (including execution of SANSML 148), thusfreeing computer 102 from having to use its own internal computingresources to execute SANSML 148.

The hardware elements depicted in computer 102 are not intended to beexhaustive, but rather are representative to highlight essentialcomponents required by the present invention. For instance, computer 102may include alternate memory storage devices such as magnetic cassettes,digital versatile disks (DVDs), Bernoulli cartridges, and the like.These and other variations are intended to be within the spirit andscope of the present invention.

As described herein, one or more embodiments of the present inventionutilize a mathematical model that shows, through the use of queuing andsimulation modeling, the impact of external factors to the migrationthroughput. From an end-to-end migration analysis, one or moreembodiments of the present invention enable the SAN subsystem and fabricto function as queuing entities. In one or more embodiments of thepresent invention, a virtualized SAN switch (i.e., a virtualizedadapter) functions as a secondary queue. In one or more embodiments ofthe present invention, the system accounts for the impact of parallelmigrations (i.e., file-based or image based) against response timemechanism in the source SAN and/or the target SAN.

Thus, the present invention presents a novel approach to SAN migration,including but not limited to sizing SAN migration throughput prior tothe SAN migration. In the prior art, the line speed between the two SANdevices was assumed to be the limiting factor. The present invention,however, also takes the ability of the hardware and other resources inthe source SAN and the target SAN into account (such as the IOPSavailable and the sequential transfer rate), as well as any otherworkloads currently migrating across the telecommunications line, whensizing SAN migrations.

Thus, one or more embodiments of the present invention enable thesetting of expectations for data transfer based on SAN hardware/resourcesizing, not just line sizing. For example, in a case where a 10 Gb/Eline connects an antiquated disk (having a storage transfer rate of only1 Gbps) in a source SAN to a current generation storage device (having astorage transfer rate of 10 Gbps) in a target SAN, only 1 Gbps can bepushed, since it is the 1 Gbps rate of the antiquated disk that limitsthe speed of the SAN migration. Similarly, if the source SAN has ahigh-speed storage device (e.g., 10 Gbps) while the target SAN has alow-speed storage device (e.g., 1 Gbps), then the limit for SANmigration is still 1 Gbps.

With reference now to FIG. 2, a high-level overview of a SAN migrationfrom a source SAN to a target SAN is presented. The SAN migrationincludes an image migration 202, which migrates configuration featuresof devices, operating systems, and/or applications within the sourceSAN, as found in the contents of server-CPU queue 206, server-NIC queue208, and Local Area Network (LAN) queue 210 (collectively depicted inblock 212); and a SAN migration 204, which migrates data itself from thesource SAN, as found in the source SAN subsystem queue 218 and thesource SAN switch ports queue 220 (collectively represented by block 222as the data in the source SAN that is being migrated to the target SAN).

Server-CPU queue 206 includes soft and hard state data related to aserver and its Central Processing Unit (CPU) used in the target SAN.Within the server's CPU is a core (i.e., circuitry that includesregisters, execution unit, instruction translators, L-1 and L-2 cache,etc.). Each core has a hard state and a soft state. The “hard state” isdefined as the information within the core that is architecturallyrequired for the core to execute a process from its present point in theprocess. The “soft state”, by contrast, is defined as information withinthe core that would improve efficiency of execution of a process, but isnot required to achieve an architecturally correct result. For example,the hard state comes from the contents of user-level registers, such asa Link and Count Register (LCR), General Purpose Registers (GPRs),Floating Point Registers (FPRs), etc. The soft state comes from thecontents of both “performance-critical” information, such as thecontents of L-1 instruction caches, L-1 data caches, address translationinformation found in a Data Translation Lookaside Buffer (DTLB) andInstruction Translation Lookaside Buffer (ITLB), as well as lesscritical information, such as contents of a Branch History Table (BHT)and all or part of the content of an L-2 cache. Whenever a softwarethread enters or leaves the core, the hard and soft states arerespectively populated or restored, either by directly populating thehard/soft states into the stated locations, or by flushing them outentirely using context switching.

In an alternative embodiment of the present invention, the content ofthe server-CPU queue 206 that is migrated during the SAN migration ishigher-level information found in a program source code, rather than thecontents of registers/caches within the core. That is, in thisembodiment the cache data is merely a pointer to a particular line ofcode being executed by the server-CPU. Thus, when the “state” of theserver-CPU is replicated in the target SAN, the running program ismerely reloaded with directions (from the pointer) to continue executionof the running program from the position within the application to whichthe pointer is pointing.

Information in the server-NIC queue 208 includes data that is in thequeue of a Network Interface Card (NIC) used by the server-CPU used inthe source SAN. That is, any data that is queued to be sent/receivedto/from a network by a NIC in the source SAN (in order to establishcommunication with the network) is found in the server-NIC queue 208.

Information in the LAN queue 210 includes data that is used by alocal/internal network in the source SAN, which allows the server-CPUand storage devices within the source SAN to communicate. That is, theLAN queue 210 includes configuration packets (rather than packetscontaining data being stored by the SAN) that are waiting to be placedon the LAN for transport to and from the server-CPU, storage devices,etc. within the source SAN.

Information found in block 212 also describes the number of paths to anI/O subsystem (e.g., storage device) within the source SAN, which isfound in I/O pathways block 214. That is, if the source SAN has “n”storage devices, then there will be “n” pathways to these storagedevices, as shown within I/O pathways block 214. In one embodiment,these pathways are shared between a single or multiple ports, such thatmultiple pathways go through a single port or through otherwise sharedmultiple ports. In another embodiment, each pathway is assigned to adifferent port.

Information found in block 212 also includes information describing thesetting of switch ports for the source SAN, which is found in the switchport settings block 216. These settings describe the permitted and/ornegotiated speed that data packets can be processed, and can bevariable, such as “low”, “medium”, or “high”. That is, if the switchport for the I/O is set to “low”, then only a low number of packets areaccepted per unit of time, thus ensuring that the storage devices areable to handle the incoming/outgoing data from the (source) SAN.However, if the switch port for the I/O is set to “High”, then more datacan go to and from the storage devices within the SAN, but at a higherrisk of overloading the storage devices, bandwidth of the SAN fabric,etc.

The source SAN subsystem queue 218 includes data within the storagedevices in the source SAN that is to be migrated.

The source SAN switch ports queue 220 includes data from the storagedevices that has been queued up for migration to the target SAN.

Thus, as noted above, information within block 222 describes the actualstorage data that is to be migrated from the source SAN to the targetSAN.

Information from the image migration 202 and the SAN migration 204 isthen passed to a migration system, such as the migration system—telecom224, which is a network (e.g., network 128 shown in FIG. 1) thatcommunicates data from the source SAN (e.g., source SAN 152 shown inFIG. 1) to a target SAN (e.g., target SAN 154 shown in FIG. 1), which ispart of the “To Be Datacenter” 226 shown in FIG. 2.

Depending on the criticality of applications, the quantity of data to bemoved and allowable downtime, there are a variety of tools thatorganizations can use to migrate data in a SAN migration. Thus, variousembodiments of the present invention utilize one or more of thefollowing SAN migration techniques.

Offline Migration Methods

Offline migration methods require that applications be taken offlineduring data movement, and therefore are suitable only when significantdowntime can be tolerated.

One type of offline migration is to restore from backup tapes. Thismethod involves making a backup copy of data, then taking the associatedarrays and/or servers offline to ensure that no new data is added. Thedata is then restored from the backup tapes to the new arrays and/orservers. Once the restore process is complete, the systems are broughtonline.

Another type of offline migration is to use a File Transfer Protocol(FTP) transfer. This method involves manually copying files from thesource systems to the target systems via File Transfer Protocol (FTP).

Online Migration Methods

Online migration methods generally allow data movement whileapplications are up and running Online migration methods includearray-based replication, volume management or replication, andhost-based mirroring.

Array-based replication moves arrays of data between similar types ofstorage devices found in the source SAN and the target SAN.

Volume management or replication maps the logical view of storage spacewith the actual physical disks in the source SAN, and then maps thisvolume to a logical view in the target SAN.

Host-based mirroring or replication solutions provide file-by-file datamovement to create a secondary data copy of data from the source SAN onthe target SAN. Thus, a server, acting as a host, facilitates thecreation of different copies of files during SAN migration.

In addition, on-line migration can utilize migration from backup tapesand/or FTP transfers as discussed above with regard to offlinemigration.

These types of SAN migration are exemplary only, and are not to beconstrued as limiting the scope of the present invention.

In accordance with various embodiments of the present invention, thefollowing parameters are taken into account when sizing and/orperforming a SAN migration.

SAN subsystem as queuing entity—measured by the IOPS available. Thisparameter highlights the difference between older technology disks(e.g., pushing 10-12K Input/output Operations Per Second—IOPS) versusnewer technology (e.g., pushing 50K IOPS). This is a deterministicvalue.

SAN switch virtualization—measured by switch setting. In many cases theswitch is set to “low” which degrades the throughput rate on purpose toensure lack of production impact by elongation of response times due tohard drive contention. Alternative settings include, but are not limitedto, low/medium/high. When multiple customers are going through the line,this further impacts the throughput available. In one or moreembodiments of the present invention, SAN virtualized switches that usecommon outsources are set to only accept a 1 to 4 Gbps transfer.

Throughput benchmark for reads and writes at the source and destinationsite. This is the sequential transfer rate that can be continuouslysustained, based on the abilities of the source SAN (including those ofthe storage device discussed in reference to block 212 in FIG. 2) aswell as those of the target SAN (e.g., the “To Be Datacenter” 226 shownin FIG. 2).

Components

The SAN subsystem as a queuing entity can be solved by a generalizedM/M/1 queue as the arrivals (characterized by the blocks of datamigrating) occur at ë according to a Poisson process. The M/M/1 processdescribes a system where arrivals form a single queue (through a singleport) and are governed by a Poisson process, there are “c” servers (thenumber of networking segments that can be processed in parallel, usuallydependent on the number of ports assigned on the SAN switch), and jobservice times are exponentially distributed. Note that in otherapplications, there will not be an infinite queue and the system canbecome unstable, resulting in either death of packets or instability ofthe system.

Thus, lambda is the arrival rate of data packets at the target SAN, ì isthe service rate of the target SAN, and rho is utilization whererho=ë/ì, assuming that rho<1 and the system is stable.

Other workloads may be migrating concurrently. Such workloads areinterleaved through the migration line when there is a SAN migration anda corresponding image migration, thus adding additional workload.However, the two workloads may have a different behavior. One may bemigrating on a TCP/IP basis (e.g., in a backup process) and need to beindividually sized. Since this is a straight line utilization, this canbe simply measured in percentage of line utilization (i.e., totalworkloads running at 20 Mbps or 10% line utilization).

SAN Switch Virtualization is utilized in one or more embodiments of thepresent invention. The element is provided as a simulation between 0 andthe switch port size (usually 4 Gbps or 8 Gbps). This element isprovided as a simulation of existing work utilizing the SAN and the SANport. In one or more embodiments, two or more simulations are run,including a simulation for a lower work throughput denoting non-primetimes and another simulation for higher work throughput denoting primetime processing. These simulations provide an estimate of the workflowgoing through the SAN, either by Mbps or percentage of line utilization,and show how much available capacity at the port level is available forSAN data migration activities when compared against productionutilization of the switch.

Throughput benchmarks for reads and writes at the source and destinationsite (the sequential transfer rate that can be continuously besustained) give the usable hardware capacity of the environment.

With reference now to FIG. 3, a high-level flow-chart of a SAN migrationis presented.

A SAN subsystem queue utilization for SAN subsystem queue 318 (analogousto element 218 in FIG. 2) is calculated as the arrival rate divided bythe service time, giving the value P, which is reported as Mbps (element302). In one or more embodiments, this information is derived from anexamination of the SAN components by the presently described system.

The concurrent migration workloads 304 are then obtained as a straightcalculation of Mbps, depicted in element 306 as C.

The SAN Switch Virtualization simulation is then run in block 308,showing the available switch capacity S (element 310) based on theswitch size (number of ports) and each port's port speed (usually 4 Mbpsor 8 Mbps).

The capacity (i.e., the continuous sequential transfer rate) of thedisks themselves shown in element 312 is then calculated (shown as “T”in circle 314).

All of the determined speeds/capacities are then input into a total Mbpssizing system 301 (e.g., computer 102 shown in FIG. 1), leading to adetermination of the amount of time needed for the data transfer fromone SAN to another SAN (block 303).

These results lead to FIG. 4, in which the following exemplary resultsare derived.

Assume that the SAN subsystem queue can be calculated at 30 Mbpstransfer rate (P=30). When looking at the Concurrent MigrationWorkloads, assume that a 10 Mbps transfer rate (C=10) is determined. TheSAN Switch Virtualization shows that when run between 0 Gbps and 4 Gbps,an average at 1.5 Gbps (or 1540 Mbps) results, such that S=2556 Mbps(5=(4*1024)−1540=2556 Mbps switch capacity available). The SequentialTransfer rate that can be handled in this system is determined to be 300Mbps (T=300) (block 402).

Therefore, since T<S, the total throughput (usable) limiting factor is300 Mbps. The Concurrent Migration workloads use 10 Mbps, so the totalthroughput available for SAN migration is 290 Mbps (block 404). Whenproduction workloads are running, these workloads require 30 Mbps. Ifthe system utilizes only 10 Mbps, the rest of the capacity available onthe system is available for use. That is, if only 10 Mbps were utilized(following the rate of SAN transfer used by the concurrent migrationworkloads 304), then the total transfer time for 15 GB (120,000 Mb)would equal 8.33 minutes (120,000/10=12,000/(1440)), even though 290Mbps of bandwidth are actually available. However, if the system usesthe entire available capacity available (290 Mbps during non-productiontimes), then 15 GB (120,000 Mb) would take 0.29 minutes(120,000/290=413/(1440)=0.29 minutes). Even during with production timesin which 30 Mbps are required for the existing workload (block 406), thesystem will still have available 290 Mbps-30 Mbps (260 Mbps).

Thus, when dealing with petabyte sized datacenter migrations, adifference of 8.33 vs. 0.29 minutes can significantly cut costs, time,and resource usage, thereby providing a significant improvement over theprior art that used only 10 Mbps (by following the constraints of theconcurrent migration workloads 304). That is, by accurately predictingthe bandwidth available for a SAN migration, costs are reduced, sinceSAN migration jobs can be efficiently queued and scheduled withoutunnecessary wait times.

With reference now to FIG. 5, a high-level flow chart of one or moresteps performed by one or more processors to size SAN storage migrationsis presented.

After initiator block 502, one or more processors determine Input/outputOperations Per Second (IOPS) and throughput of hardware devicesoperatively coupled to a target Storage Area Network (SAN) and/or asource SAN prior to a SAN migration from the source SAN to the targetSAN (block 504).

As depicted in block 506, one or more processors determine an estimatedtime and size of the SAN migration based on the IOPS and the throughputof the hardware devices.

As described in block 508, one or more processors configure transmissionresources available to the source SAN and/or the target SAN to comportwith the estimated time and size of the SAN migration. That is, based onhow long it will take to migrate the SAN, resources are reallocated suchthat if the time will take too long, additional resources (e.g., ports,networks, switches, storage devices, etc.) are reallocated to theprocess. Alternatively, if the time required is minimal (i.e., thesystem is over-engineered with too many resources), then some of theresources are taken off line by the system.

The flow-chart ends at terminator block 510.

Thus, the present invention provides the utility of accurately sizingSAN storage migrations in a way that is not available in the prior art,thereby increasing the efficiency of resource usage.

In one or more alternative embodiments of the present invention, one ormore processors further determine the estimated time and size of the SANmigration by using a SAN subsystem of the target SAN as a queuingentity, where the SAN subsystem simulates the IOPS of the hardwaredevices operatively coupled to the target SAN. That is, by simulatingthe IOPS of the hardware devices by a SAN subsystem during SAN migrationsizing, a more accurate determination is made of the SAN sizing thanthat provided in the prior art.

In one or more embodiments of the present invention, one or moreprocessors further determine the estimated time and size of the SANmigration by using a SAN virtualized switch, wherein the SAN virtualizedswitch simulates the throughput of the hardware devices operativelycoupled to the target SAN by emulating switch ports used by the targetSAN. That is, by simulating the throughput of the hardware devices by aSAN subsystem during SAN migration sizing, a more accurate determinationis made of the SAN sizing than that provided in the prior art.

In one or more embodiments of the present invention, one or moreprocessors determine the IOPS and throughput of the hardware devicesoperatively coupled to the SAN based on an M/M/c queue of the SANvirtualized switch, wherein the M/M/1 queue represents a queue length ofa queue for the SAN virtualized switch based on an arrival rate (M/) ofpackets at the SAN virtualized switch and a departure (/M) rate ofpackets from the SAN virtualized switch based on the number of availableservers (c). By examining the M/M/c queue while determining the IOPS andthroughput of the hardware devices, a more accurate determination ismade of the SAN sizing than that provided in the prior art.

In one or more embodiments of the present invention, one or moreprocessors determine the arrival rate and the departure rate at theserver by a Poisson process that predicts the arrival rate and thedeparture rate at different predicted time points during the SANmigration. That is, the predicted number of arriving packets (lambda)during a period of time divided by a service rate mu (e.g., how manypackets can be handled by the server during that same period of time)leads to rho, which represents the usage rate of the device. That is, if10 packets arrive during a certain period of time at a device that canhandle 50 packets during that period of time, then the device isoperating at 20% (10/50) capacity. Note that the Poisson process isused, since the period of time may vary during the SAN migration, suchthat rho will likewise vary during the SAN migration.

In one or more embodiments of the present invention, one or moreprocessors predict a root cause of a throughput slowdown during the SANmigration based on the IOPS and the throughput of the hardware devices.For example, if the maximum IOPS/throughput allows only 260 Mbps to beprocessed in the SAN migration, then in FIG. 4 the switch capacity shownin element 310 of 2556 Mbps cannot be a limitation/root cause of thethroughput slowdown.

As described herein, in one or more embodiments of the presentinvention, one or more processors determine the throughput of hardwaredevices operatively coupled to a target SAN according to a productionthroughput, wherein the production throughput is equal to totalavailable bandwidth for SAN migration minus bandwidth used by currentlyrunning production workloads on the target SAN, as described in detailin FIG. 3 and FIG. 4.

In one or more embodiments, the present invention is implemented in acloud environment. It is understood in advance that although thisdisclosure includes a detailed description on cloud computing,implementation of the teachings recited herein are not limited to acloud computing environment. Rather, embodiments of the presentinvention are capable of being implemented in conjunction with any othertype of computing environment now known or later developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure comprising anetwork of interconnected nodes.

Referring now to FIG. 6, a schematic of an example of a cloud computingnode is shown. Cloud computing node 10 is only one example of a suitablecloud computing node and is not intended to suggest any limitation as tothe scope of use or functionality of embodiments of the inventiondescribed herein. Regardless, cloud computing node 10 is capable ofbeing implemented and/or performing any of the functionality set forthhereinabove.

In cloud computing node 10 there is a computer system/server 12, whichis operational with numerous other general purpose or special purposecomputing system environments or configurations. Examples of well-knowncomputing systems, environments, and/or configurations that may besuitable for use with computer system/server 12 include, but are notlimited to, personal computer systems, server computer systems, thinclients, thick clients, hand-held or laptop devices, multiprocessorsystems, microprocessor-based systems, set top boxes, programmableconsumer electronics, network PCs, minicomputer systems, mainframecomputer systems, and distributed cloud computing environments thatinclude any of the above systems or devices, and the like.

Computer system/server 12 may be described in the general context ofcomputer system-executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 12 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 6, computer system/server 12 in cloud computing node 10is shown in the form of a general-purpose computing device. Thecomponents of computer system/server 12 may include, but are not limitedto, one or more processors or processing units 16, a system memory 28,and a bus 18 that couples various system components including systemmemory 28 to processor 16.

Bus 18 represents one or more of any of several types of bus structures,including a memory bus or memory controller, a peripheral bus, anaccelerated graphics port, and a processor or local bus using any of avariety of bus architectures. By way of example, and not limitation,such architectures include Industry Standard Architecture (ISA) bus,Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnects (PCI) bus.

Computer system/server 12 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 12, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 28 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 30 and/or cachememory 32. Computer system/server 12 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 34 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 18 by one or more datamedia interfaces. As will be further depicted and described below,memory 28 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 40, having a set (at least one) of program modules 42,may be stored in memory 28 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. Program modules 42 generally carry out the functions and/ormethodologies of embodiments of the invention as described herein.

Computer system/server 12 may also communicate with one or more externaldevices 14 such as a keyboard, a pointing device, a display 24, etc.;one or more devices that enable a user to interact with computersystem/server 12; and/or any devices (e.g., network card, modem, etc.)that enable computer system/server 12 to communicate with one or moreother computing devices. Such communication can occur via Input/output(I/O) interfaces 22. Still yet, computer system/server 12 cancommunicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 20. As depicted, network adapter 20communicates with the other components of computer system/server 12 viabus 18. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 12. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

Referring now to FIG. 7, illustrative cloud computing environment 50 isdepicted. As shown, cloud computing environment 50 comprises one or morecloud computing nodes 10 with which local computing devices used bycloud consumers, such as, for example, personal digital assistant (PDA)or cellular telephone 54A, desktop computer 54B, laptop computer 65C,and/or automobile computer system 54N may communicate. Nodes 10 maycommunicate with one another. They may be grouped (not shown) physicallyor virtually, in one or more networks, such as Private, Community,Public, or Hybrid clouds as described hereinabove, or a combinationthereof. This allows cloud computing environment 50 to offerinfrastructure, platforms and/or software as services for which a cloudconsumer does not need to maintain resources on a local computingdevice. It is understood that the types of computing devices 54A-N shownin FIG. 7 are intended to be illustrative only and that computing nodes10 and cloud computing environment 50 can communicate with any type ofcomputerized device over any type of network and/or network addressableconnection (e.g., using a web browser).

Referring now to FIG. 8, a set of functional abstraction layers providedby cloud computing environment 50 (FIG. 7) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 8 are intended to be illustrative only and embodiments of theinvention are not limited thereto. As depicted, the following layers andcorresponding functions are provided:

Hardware and software layer 60 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 61; RISC(Reduced Instruction Set Computer) architecture based servers 62;servers 63; blade servers 64; storage devices 65; and networks andnetworking components 66. In some embodiments, software componentsinclude network application server software 67 and database software 68.

Virtualization layer 70 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers71; virtual storage 72; virtual networks 73, including virtual privatenetworks; virtual applications and operating systems 74; and virtualclients 75.

In one example, management layer 80 may provide the functions describedbelow. Resource provisioning 81 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 82provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may comprise applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 83 provides access to the cloud computing environment forconsumers and system administrators. Service level management 84provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 85 provide pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 90 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation 91; software development and lifecycle management 92; virtualclassroom education delivery 93; data analytics processing 94;transaction processing 95; and SAN migration sizing processing 96 (forsizing SAN storage migration as described herein).

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the presentinvention. As used herein, the singular forms “a”, “an” and “the” areintended to include the plural forms as well, unless the context clearlyindicates otherwise. It will be further understood that the terms“comprises” and/or “comprising,” when used in this specification,specify the presence of stated features, integers, steps, operations,elements, and/or components, but do not preclude the presence oraddition of one or more other features, integers, steps, operations,elements, components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of various embodiments of the present invention has beenpresented for purposes of illustration and description, but is notintended to be exhaustive or limited to the present invention in theform disclosed. Many modifications and variations will be apparent tothose of ordinary skill in the art without departing from the scope andspirit of the present invention. The embodiment was chosen and describedin order to best explain the principles of the present invention and thepractical application, and to enable others of ordinary skill in the artto understand the present invention for various embodiments with variousmodifications as are suited to the particular use contemplated.

Any methods described in the present disclosure may be implementedthrough the use of a VHDL (VHSIC Hardware Description Language) programand a VHDL chip. VHDL is an exemplary design-entry language for FieldProgrammable Gate Arrays (FPGAs), Application Specific IntegratedCircuits (ASICs), and other similar electronic devices. Thus, anysoftware-implemented method described herein may be emulated by ahardware-based VHDL program, which is then applied to a VHDL chip, suchas a FPGA.

Having thus described embodiments of the present invention of thepresent application in detail and by reference to illustrativeembodiments thereof, it will be apparent that modifications andvariations are possible without departing from the scope of the presentinvention defined in the appended claims.

What is claimed is:
 1. A computer-implemented method of sizing a StorageArea Network (SAN) storage migration, the computer-implemented methodcomprising: determining, by one or more processors, Input/outputOperations Per Second (IOPS) and throughput of hardware devicesoperatively coupled to a target Storage Area Network (SAN) prior to aSAN migration from a source SAN to the target SAN; determining, by oneor more processors, an estimated time and size of the SAN migrationbased on the IOPS and the throughput of the hardware devices; andconfiguring, by one or more processors, transmission resources availableto the source SAN to comport with the estimated time and size of the SANmigration.
 2. The computer-implemented method of claim 1, furthercomprising: further determining, by one or more processors, theestimated time and size of the SAN migration by using a SAN subsystem ofthe target SAN as a queuing entity, wherein the SAN subsystem simulatesthe IOPS of the hardware devices operatively coupled to the target SAN.3. The computer-implemented method of claim 1, further comprising:further determining, by one or more processors, the estimated time andsize of the SAN migration by using a SAN virtualized switch, wherein theSAN virtualized switch simulates the throughput of the hardware devicesoperatively coupled to the target SAN by emulating switch ports used bythe target SAN.
 4. The computer-implemented method of claim 3, furthercomprising: determining, by one or more processors, the IOPS andthroughput of the hardware devices operatively coupled to the target SANbased on an M/M/1 queue of the SAN virtualized switch, wherein the M/M/1queue represents a queue length of a queue for the SAN virtualizedswitch based on an arrival rate of packets at the SAN virtualized switchand a departure rate of packets from the SAN virtualized switch.
 5. Thecomputer-implemented method of claim 4, further comprising: determining,by one or more processors, the arrival rate and the departure rate by aPoisson process that predicts the arrival rate and the departure rate atdifferent predicted time points during the SAN migration.
 6. Thecomputer-implemented method of claim 1, further comprising: predicting,by one or more processors, a root cause of a throughput slowdown duringthe SAN migration based on the IOPS and the throughput of the hardwaredevices.
 7. The computer-implemented method of claim 1, furthercomprising: determining, by one or more processors, the throughput ofhardware devices operatively coupled to a target SAN according to aproduction throughput, wherein the production throughput is equal tototal available bandwidth for SAN migration minus bandwidth used bycurrently running production workloads on the target SAN.
 8. A computerprogram product for sizing a Storage Area Network (SAN) storagemigration, the computer program product comprising a non-transitorycomputer readable storage medium having program code embodied therewith,the program code readable and executable by a processor to perform amethod comprising: determining Input/output Operations Per Second (IOPS)and throughput of hardware devices operatively coupled to a sourceStorage Area Network (SAN) prior to a SAN migration from the source SANto a target SAN; determining an estimated time and size of the SANmigration based on the IOPS and the throughput of the hardware devices;and configuring transmission resources available to the source SAN tocomport with the estimated time and size of the SAN migration.
 9. Thecomputer program product of claim 8, wherein the method furthercomprises: further determining the estimated time and size of the SANmigration by using a SAN subsystem of the target SAN as a queuingentity, wherein the SAN subsystem simulates the IOPS of the hardwaredevices operatively coupled to the target SAN.
 10. The computer programproduct of claim 8, wherein the method further comprises: furtherdetermining the estimated time and size of the SAN migration by using aSAN virtualized switch, wherein the SAN virtualized switch simulates thethroughput of the hardware devices operatively coupled to the target SANby emulating switch ports used by the target SAN.
 11. The computerprogram product of claim 10, wherein the method further comprises:determining the IOPS and throughput of the hardware devices operativelycoupled to the target SAN based on an M/M/1 queue of the SAN virtualizedswitch, wherein the M/M/1 queue represents a queue length of a queue forthe SAN virtualized switch based on an arrival rate of packets at theSAN virtualized switch and a departure rate of packets from the SANvirtualized switch.
 12. The computer program product of claim 11,wherein the method further comprises: determining the arrival rate andthe departure rate by a Poisson process that predicts the arrival rateand the departure rate at different predicted time points during the SANmigration.
 13. The computer program product of claim 8, wherein themethod further comprises: predicting a root cause of a throughputslowdown during the SAN migration based on the IOPS and the throughputof the hardware devices.
 14. The computer program product of claim 8,wherein the method further comprises: determining the throughput ofhardware devices operatively coupled to a target SAN according to aproduction throughput, wherein the production throughput is equal tototal available bandwidth for SAN migration minus bandwidth used bycurrently running production workloads on the target SAN.
 15. A computersystem comprising: a processor, a computer readable memory, and anon-transitory computer readable storage medium; first programinstructions to determine Input/output Operations Per Second (IOPS) andthroughput of hardware devices operatively coupled to a target StorageArea Network (SAN) prior to a SAN migration from a source SAN to thetarget SAN; second program instructions to determine an estimated timeand size of the SAN migration based on the IOPS and the throughput ofthe hardware devices; and third program instructions to configuretransmission resources available to the source SAN to comport with theestimated time and size of the SAN migration; and wherein the first,second, and third program instructions are stored on the non-transitorycomputer readable storage medium for execution by one or more processorsvia the computer readable memory.
 16. The computer system of claim 15,further comprising: fourth program instructions to further determine theestimated time and size of the SAN migration by using a SAN subsystem ofthe target SAN as a queuing entity, wherein the SAN subsystem simulatesthe IOPS of the hardware devices operatively coupled to the target SAN;and wherein the fourth program instructions are stored on thenon-transitory computer readable storage medium for execution by one ormore processors via the computer readable memory.
 17. The computersystem of claim 15, further comprising: fourth program instructions tofurther determine the estimated time and size of the SAN migration byusing a SAN virtualized switch, wherein the SAN virtualized switchsimulates the throughput of the hardware devices operatively coupled tothe target SAN by emulating switch ports used by the target SAN; andwherein the fourth program instructions are stored on the non-transitorycomputer readable storage medium for execution by one or more processorsvia the computer readable memory.
 18. The computer system of claim 17,further comprising: fifth program instructions to determine the IOPS andthroughput of the hardware devices operatively coupled to the target SANbased on an M/M/1 queue of the SAN virtualized switch, wherein the M/M/1queue represents a queue length of a queue for the SAN virtualizedswitch based on an arrival rate of packets at the SAN virtualized switchand a departure rate of packets from the SAN virtualized switch; andwherein the fifth program instructions are stored on the non-transitorycomputer readable storage medium for execution by one or more processorsvia the computer readable memory.
 19. The computer system of claim 18,further comprising: sixth program instructions to determine the arrivalrate and the departure rate by a Poisson process that predicts thearrival rate and the departure rate at different predicted time pointsduring the SAN migration; and wherein the sixth program instructions arestored on the non-transitory computer readable storage medium forexecution by one or more processors via the computer readable memory.20. The computer system of claim 15, further comprising: fourth programinstructions to predict a root cause of a throughput slowdown during theSAN migration based on the IOPS and the throughput of the hardwaredevices; and wherein the fourth program instructions are stored on thenon-transitory computer readable storage medium for execution by one ormore processors via the computer readable memory.